apps/commerce-api/src/test/java/com/loopers/domain/example/ExampleModelTest.java (1)

35-63: 경계값 테스트 케이스 누락 가능성이 있다.

현재 테스트는 다음만 검증한다:

• name: 공백 문자열(" ")
• description: 빈 문자열("")

운영 환경에서 NPE 또는 예상치 못한 예외가 발생할 수 있으므로, 다음 경계값 케이스 추가를 권장한다:

• null 입력 (name, description 각각)
• name이 빈 문자열("")인 경우
• description이 공백 문자열(" ")인 경우

추가 테스트가 없으면 도메인 모델의 null 처리 로직이 실제로 동작하는지 검증할 수 없다.

♻️ 추가 테스트 케이스 예시

`@DisplayName`("제목이 null이면 예외가 발생한다")
`@Test`
void throwsOnNullTitle() {
    // act
    CoreException result = assertThrows(CoreException.class, () -> {
        new ExampleModel(null, "설명");
    });

    // assert
    assertThat(result.getErrorType()).isEqualTo(ErrorType.BAD_REQUEST);
}

`@DisplayName`("설명이 null이면 예외가 발생한다")
`@Test`
void throwsOnNullDescription() {
    // act
    CoreException result = assertThrows(CoreException.class, () -> {
        new ExampleModel("제목", null);
    });

    // assert
    assertThat(result.getErrorType()).isEqualTo(ErrorType.BAD_REQUEST);
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/example/ExampleModelTest.java`
around lines 35 - 63, Add missing boundary tests for ExampleModel to cover null
and empty/blank variants: create new test methods in ExampleModelTest (mirroring
throwsOnBlankTitle and throwsOnEmptyDescription) that assert CoreException is
thrown with ErrorType.BAD_REQUEST when new ExampleModel is constructed with name
== null, description == null, name == "" (empty string), and description == "  
" (blank); ensure each test uses assertThrows(CoreException.class, () -> new
ExampleModel(...)) and asserts result.getErrorType() equals
ErrorType.BAD_REQUEST so null-handling and empty/blank handling in ExampleModel
are verified.

apps/commerce-api/src/test/java/com/loopers/domain/example/ExampleServiceIntegrationTest.java (1)

29-32: @BeforeEach 추가를 권장한다

현재 @AfterEach에서만 테이블을 truncate하고 있다. 이전 테스트가 예외로 종료되거나 테스트 실행 순서가 변경될 경우, 테스트 시작 시점의 데이터 상태를 보장하지 못해 플래키 테스트가 발생할 수 있다.

@BeforeEach에서도 cleanup을 수행하면 각 테스트의 초기 상태를 명시적으로 보장할 수 있다.

♻️ 제안하는 수정안

+    `@BeforeEach`
+    void setUp() {
+        databaseCleanUp.truncateAllTables();
+    }
+
     `@AfterEach`
     void tearDown() {
         databaseCleanUp.truncateAllTables();
     }

BeforeEach import도 추가해야 한다:

import org.junit.jupiter.api.BeforeEach;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/example/ExampleServiceIntegrationTest.java`
around lines 29 - 32, Add a `@BeforeEach` setup that calls
databaseCleanUp.truncateAllTables() to guarantee a clean DB state before each
test (in addition to the existing `@AfterEach` tearDown method), and import
org.junit.jupiter.api.BeforeEach; locate the ExampleServiceIntegrationTest class
and add a setup method (e.g., setUp()) that invokes
databaseCleanUp.truncateAllTables() so each test starts from a known state.

.claude/settings.json (1)

9-10: ~/.zshrc 소싱 시 예상치 못한 지연이나 부작용이 발생할 수 있다.

운영 관점에서 ~/.zshrc에는 대화형 셸 설정(프롬프트, 자동완성, 플러그인 등)이 포함될 수 있어 hook 실행 시 불필요한 오버헤드가 발생하거나 예상치 못한 출력이 생길 수 있다. 또한 2>/dev/null로 에러를 숨기면 디버깅이 어려워진다.

수정 권장사항:

• 환경 변수만 필요하다면 ~/.zshenv 또는 별도 env 파일 소싱을 고려하다
• 또는 .env 파일에서 직접 변수를 로드하는 방식으로 변경하다

대안 예시

-"command": "source ~/.zshrc 2>/dev/null; python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/tdd-notion-logger.py",
+"command": "[ -f \"$CLAUDE_PROJECT_DIR/.env\" ] && export $(grep -v '^#' \"$CLAUDE_PROJECT_DIR/.env\" | xargs); python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/tdd-notion-logger.py",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/settings.json around lines 9 - 10, The command currently sources
~/.zshrc which can cause interactive-shell side effects and hides errors via
2>/dev/null; change the "command" value so it does not source ~/.zshrc — instead
either source a non-interactive env file (e.g., ~/.zshenv) or load a project
.env before running the hook, and remove the silence redirect so failures
surface; update the command that invokes .claude/hooks/tdd-notion-logger.py (the
"command" key) to explicitly export or source only needed env vars (or use a
dotenv loader) and ensure no 2>/dev/null redirection remains so errors are
visible.

.claude/hooks/tdd-notion-logger.py (3)

442-466: URL 스킴 검증을 추가하여 S310 경고를 해결하고 방어적 코딩을 적용하는 것이 좋다.

현재 URL이 https://api.notion.com으로 하드코딩되어 있어 실질적인 위험은 낮으나, 향후 코드 변경 시 의도치 않은 스킴(file:, ftp: 등) 사용을 방지하기 위해 명시적 검증이 권장된다.

방어적 코딩 적용 예시

 def append_blocks_to_notion(api_key, blocks):
     """Append blocks to the Notion page using urllib (no external deps)."""
     url = f"https://api.notion.com/v1/blocks/{NOTION_PAGE_ID}/children"
+    
+    # Defensive: ensure URL uses HTTPS scheme only
+    if not url.startswith("https://"):
+        sys.stderr.write("Security error: Non-HTTPS URL not allowed\n")
+        return
+    
     payload = json.dumps({"children": blocks}).encode("utf-8")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks/tdd-notion-logger.py around lines 442 - 466, In
append_blocks_to_notion add defensive URL validation before creating the
Request: parse the target URL (built from NOTION_PAGE_ID) with
urllib.parse.urlparse and assert the scheme is "https" (and optionally that
netloc equals "api.notion.com"); if the check fails, log/write an error and
abort (raise ValueError or return) instead of proceeding to build/execute the
urllib.request.Request. This ensures append_blocks_to_notion only sends requests
over HTTPS and prevents accidental file:/ftp: schemes.

---

17-19: NOTION_PAGE_ID 하드코딩은 환경 변수로 관리해야 한다.

운영 관점에서 Notion 페이지 ID가 하드코딩되면 페이지 변경 시 코드 수정 및 재배포가 필요하다. 또한 다른 프로젝트나 환경에서 재사용이 불가능하다.

수정안:

-NOTION_PAGE_ID = "2fc2e1bd53b2809cbd5ed9009dc775bd"
+NOTION_PAGE_ID = os.environ.get("NOTION_PAGE_ID", "")

main() 함수에서 NOTION_API_KEY와 함께 검증 로직 추가가 필요하다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks/tdd-notion-logger.py around lines 17 - 19, Replace the
hardcoded NOTION_PAGE_ID with a value read from the environment and add
validation in main(): read NOTION_PAGE_ID (and NOTION_API_KEY) from os.environ
(or equivalent env loader), validate they are present/non-empty at startup, and
fail fast with a clear error if missing; update any usages that reference the
constant NOTION_PAGE_ID to use the env-backed value, leaving NOTION_API_VERSION
and KST as-is, and put the validation logic in the main() function so the
process logs/raises an error before proceeding.

---

458-466: 에러 발생 시 컨텍스트 정보가 부족하여 디버깅이 어렵다.

운영 환경에서 Notion API 호출 실패 시, 어떤 테스트 클래스의 로깅이 실패했는지 파악하기 어렵다. 에러 메시지에 테스트 클래스명, 타임스탬프 등 컨텍스트를 포함해야 한다.

개선된 에러 핸들링

-def append_blocks_to_notion(api_key, blocks):
+def append_blocks_to_notion(api_key, blocks, context=""):
     """Append blocks to the Notion page using urllib (no external deps)."""
     url = f"https://api.notion.com/v1/blocks/{NOTION_PAGE_ID}/children"
     payload = json.dumps({"children": blocks}).encode("utf-8")
     # ... request setup ...
     except urllib.error.HTTPError as e:
         body = e.read().decode("utf-8", errors="replace")
-        sys.stderr.write(f"Notion API error {e.code}: {body}\n")
+        sys.stderr.write(f"Notion API error {e.code} [{context}]: {body}\n")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks/tdd-notion-logger.py around lines 458 - 466, The except blocks
around urllib.request.urlopen must include richer context (timestamp, test class
name, request URL/body and traceback) to aid debugging: update the handlers for
urllib.error.HTTPError and urllib.error.URLError that reference e and
e.read().decode to build and write a detailed message including datetime.now(),
the test class identifier (use the existing variable that holds the test/class
name or add a parameter like test_class or class_name if none exists), the
req.full_url or req.get_full_url(), any request payload (decode req.data if
present), the HTTP status/body (from e.read()), and the full traceback (use
traceback.format_exc()); include similar contextual details when resp.status !=
200 (use resp.status, req URL/body and timestamp). Ensure you still preserve the
original exception handling symbols (urllib.request.urlopen, req, resp,
urllib.error.HTTPError, urllib.error.URLError, e) while replacing simple
sys.stderr.write calls with the enriched message.

apps/commerce-api/src/main/java/com/loopers/domain/member/LoginId.java (1)

22-27: 로그인 ID 길이 제한 검증 추가를 권장한다.

현재 영문/숫자만 검증하고 길이 제한이 없다. 데이터베이스 컬럼 길이 제한에 의존하면 DB 오류가 발생하여 사용자에게 불명확한 에러 메시지가 전달될 수 있다. 도메인 계층에서 길이 검증을 수행하면 명확한 에러 메시지 제공이 가능하다.

♻️ 길이 검증 추가 제안

 public class LoginId {
 
     private static final Pattern PATTERN = Pattern.compile("^[a-zA-Z0-9]+$");
+    private static final int MIN_LENGTH = 4;
+    private static final int MAX_LENGTH = 20;
 
     `@Column`(name = "login_id", nullable = false, unique = true)
     private String value;
 
     public LoginId(String value) {
-        if (value == null || value.isBlank() || !PATTERN.matcher(value).matches()) {
+        if (value == null || value.isBlank()) {
+            throw new CoreException(ErrorType.INVALID_LOGIN_ID);
+        }
+        if (value.length() < MIN_LENGTH || value.length() > MAX_LENGTH) {
+            throw new CoreException(ErrorType.INVALID_LOGIN_ID);
+        }
+        if (!PATTERN.matcher(value).matches()) {
             throw new CoreException(ErrorType.INVALID_LOGIN_ID);
         }
         this.value = value;
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/commerce-api/src/main/java/com/loopers/domain/member/LoginId.java`
around lines 22 - 27, 현재 LoginId 생성자에서 영문/숫자 패턴만 검증하고 길이 검증이 없어 DB에러로 이어질 수 있으니
LoginId(String value) 내부에 길이 제한을 추가하세요: 클래스 레벨에 MIN_LENGTH/MAX_LENGTH 상수를 정의하고
생성자에서 value == null || value.isBlank() 체크 다음에 value.length()가 MIN_LENGTH 이상
MAX_LENGTH 이하인지 검사한 뒤 범위를 벗어나면 CoreException(ErrorType.INVALID_LOGIN_ID) 를 던지도록
하며 기존 PATTERN.matcher(value).matches() 호출은 길이 검사 이후에 실행되도록 변경하세요.

apps/commerce-api/src/test/java/com/loopers/domain/member/MemberAuthServiceIntegrationTest.java (1)

39-51: 인증 성공 테스트에서 추가 검증이 필요하다.

현재 테스트는 loginId 일치만 검증한다. 인증 성공 시 반환되는 MemberModel의 다른 필드들(name, birthDate, email)도 함께 검증하면 데이터 무결성을 보장할 수 있다.

💚 추가 검증 제안

  // then
- assertThat(result.loginId().value()).isEqualTo("kwonmo");
+ assertAll(
+     () -> assertThat(result.loginId().value()).isEqualTo("kwonmo"),
+     () -> assertThat(result.name().value()).isEqualTo("양권모"),
+     () -> assertThat(result.birthDate()).isEqualTo(LocalDate.of(1998, 9, 16)),
+     () -> assertThat(result.email().value()).isEqualTo("kwonmo@example.com")
+ );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/member/MemberAuthServiceIntegrationTest.java`
around lines 39 - 51, Update the returnsMemberOnValidCredentials test in
MemberAuthServiceIntegrationTest to assert the additional MemberModel fields
returned by memberAuthService.authenticate; after calling
memberAuthService.authenticate("kwonmo", "Test1234!"), add assertions on
result.name(), result.birthDate() (compare to LocalDate.of(1998, 9, 16)), and
result.email() (compare to "kwonmo@example.com") in addition to the existing
loginId assertion to ensure full data integrity.

apps/commerce-api/src/test/java/com/loopers/domain/member/MemberSignupServiceIntegrationTest.java (1)

37-116: email이 null인 경우의 회원가입 테스트가 누락되었다.

MemberModel은 email이 null이어도 생성 가능하다(MemberModelTest.createsWithNullEmail). 그러나 MemberSignupService를 통한 email 없는 회원가입 시나리오에 대한 통합 테스트가 없다. 실제 운영 환경에서 email 선택 입력 시 문제가 발생할 수 있다.

💚 email null 회원가입 테스트 추가 제안

`@DisplayName`("email 없이도 회원가입할 수 있다")
`@Test`
void createsMemberWithoutEmail() {
    // given
    String loginId = "noEmailUser";
    String password = "Test1234!";
    String name = "테스트";
    LocalDate birthDate = LocalDate.of(1990, 1, 1);

    // when
    MemberModel result = memberSignupService.signup(loginId, password, name, birthDate, null);

    // then
    assertAll(
        () -> assertThat(result.getId()).isNotNull(),
        () -> assertThat(result.email()).isNull()
    );
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/member/MemberSignupServiceIntegrationTest.java`
around lines 37 - 116, Add an integration test that verifies signup with a null
email works: create a new test method (e.g., createsMemberWithoutEmail) that
calls memberSignupService.signup(loginId, password, name, birthDate, null) and
then asserts the returned MemberModel (MemberModel result) has a non-null id and
that result.email() is null; place this alongside the other Signup nested tests
and use the same conventions as existing tests (DisplayName, `@Test`) to ensure
coverage for the email-null signup path.

apps/commerce-api/src/main/java/com/loopers/application/member/MemberInfo.java (1)

9-25: email null 처리 로직이 중복되어 있다.

from()과 fromWithMaskedName() 메서드에서 email null 처리 로직이 동일하게 반복된다. 현재는 간단한 로직이지만, 추후 email 처리 로직이 복잡해지면 유지보수 부담이 증가한다.

♻️ 헬퍼 메서드 추출 제안

+ private static String extractEmail(MemberModel model) {
+     return model.email() != null ? model.email().value() : null;
+ }
+
  public static MemberInfo from(MemberModel model) {
      return new MemberInfo(
          model.loginId().value(),
          model.name().value(),
          model.birthDate(),
-         model.email() != null ? model.email().value() : null
+         extractEmail(model)
      );
  }

  public static MemberInfo fromWithMaskedName(MemberModel model) {
      return new MemberInfo(
          model.loginId().value(),
          model.name().masked(),
          model.birthDate(),
-         model.email() != null ? model.email().value() : null
+         extractEmail(model)
      );
  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/application/member/MemberInfo.java`
around lines 9 - 25, from()와 fromWithMaskedName()에서 동일한 이메일 null 처리 로직이 중복되어
있으므로 중복 제거를 위해 이메일 값을 반환하는 private static 헬퍼 메서드(예: getEmailValue(MemberModel
model) 또는 extractEmail(MemberModel model))를 추가하고, 현재 각 메서드에서 사용 중인 model.email()
!= null ? model.email().value() : null 구문을 해당 헬퍼 메서드 호출로 교체하세요; 참조 대상:
MemberInfo.from, MemberInfo.fromWithMaskedName, MemberModel.email(),
MemberInfo(생성자).

apps/commerce-api/src/main/java/com/loopers/domain/member/Email.java (1)

15-44: toString() 미구현으로 인한 민감정보 노출 위험이 있다.

toString()이 구현되지 않아 기본 Object.toString() 또는 IDE 자동생성 시 email 값이 그대로 로그에 노출될 수 있다. 운영 환경에서 로그 수집 시 PII(개인식별정보) 유출 위험이 존재한다.

마스킹된 형태로 toString()을 구현하거나, 최소한 값을 노출하지 않는 형태로 재정의를 권장한다.

🛡️ 마스킹된 toString() 구현 제안

  `@Override`
  public int hashCode() {
      return Objects.hashCode(value);
  }
+
+ `@Override`
+ public String toString() {
+     if (value == null) return "Email[null]";
+     int atIndex = value.indexOf('@');
+     if (atIndex <= 1) return "Email[***]";
+     return "Email[" + value.charAt(0) + "***" + value.substring(atIndex) + "]";
+ }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/commerce-api/src/main/java/com/loopers/domain/member/Email.java` around
lines 15 - 44, Implement a safe toString() in the Email class to avoid logging
the raw PII: add an `@Override` public String toString() that does not return the
plain value field (or value()), e.g. return a masked representation (mask the
local part leaving only first/last char or return "[REDACTED EMAIL]") so logs
never contain the full email; ensure the method references the existing value
field (or value()) and does not change equals(Object) or hashCode().

apps/commerce-api/src/test/java/com/loopers/domain/member/MemberModelTest.java (1)

23-66: 생성 실패 케이스에 대한 테스트가 누락되었다.

MemberModel 생성 시 필수 필드(loginId, name, birthDate)가 null인 경우의 예외 처리 테스트가 없다. 운영 환경에서 잘못된 입력이 들어올 경우 예상치 못한 동작이 발생할 수 있다.

다음 케이스에 대한 테스트 추가를 권장한다:

• loginId가 null인 경우
• name이 null인 경우
• birthDate가 null인 경우

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/member/MemberModelTest.java`
around lines 23 - 66, Add negative tests that assert MemberModel's constructor
throws when required fields are null: create three `@Test` methods (e.g.,
createsFailsWhenLoginIdNull, createsFailsWhenNameNull,
createsFailsWhenBirthDateNull) which call new MemberModel(...) with null for
LoginId, MemberName, and birthDate respectively (keep other args valid like
encodedPassword and email) and use assertThrows(NullPointerException.class, ()
-> new MemberModel(...)) to verify the exception; reference the MemberModel
constructor and matchesPassword usage to keep the tests consistent with existing
setup.

apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java (3)

34-34: 미사용 의존성 MemberJpaRepository 제거 필요

MemberJpaRepository가 주입되었으나 테스트 코드에서 사용되지 않는다. 불필요한 의존성은 테스트 의도를 흐리고 유지보수 비용을 증가시킨다.

♻️ 수정 제안

-    private final MemberJpaRepository memberJpaRepository;
     private final DatabaseCleanUp databaseCleanUp;

     `@Autowired`
     public MemberV1ApiE2ETest(
         TestRestTemplate testRestTemplate,
-        MemberJpaRepository memberJpaRepository,
         DatabaseCleanUp databaseCleanUp
     ) {
         this.testRestTemplate = testRestTemplate;
-        this.memberJpaRepository = memberJpaRepository;
         this.databaseCleanUp = databaseCleanUp;
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java`
at line 34, Remove the unused MemberJpaRepository dependency from the
MemberV1ApiE2ETest class: delete the private final MemberJpaRepository field
(and its constructor parameter or `@Autowired` injection if present) so the test
class no longer declares or injects MemberJpaRepository; ensure any imports for
MemberJpaRepository are also removed and the test compiles without that unused
dependency.

---

193-211: 비밀번호 변경 후 새 비밀번호로 인증 성공 여부 검증 필요

returns200OnValidRequest 테스트가 200 응답만 확인하고, 변경된 비밀번호로 실제 인증이 성공하는지 검증하지 않는다. 운영 환경에서 비밀번호 변경 로직이 정상 동작하지 않아도 테스트가 통과할 수 있다.

♻️ 수정 제안

         // then
         assertTrue(response.getStatusCode().is2xxSuccessful());
+
+        // 변경된 비밀번호로 인증 성공 확인
+        ParameterizedTypeReference<ApiResponse<MemberV1Dto.MemberResponse>> meResponseType =
+            new ParameterizedTypeReference<>() {};
+        ResponseEntity<ApiResponse<MemberV1Dto.MemberResponse>> meResponse =
+            testRestTemplate.exchange(ENDPOINT_ME, HttpMethod.GET,
+                new HttpEntity<>(null, authHeaders("kwonmo", "NewPass5678!")),
+                meResponseType);
+        assertTrue(meResponse.getStatusCode().is2xxSuccessful());
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java`
around lines 193 - 211, The test returns200OnValidRequest only asserts a 2xx
status; extend it to verify the password actually changed by attempting
authentication with the new password (and optionally asserting the old password
fails). After calling the change-password endpoint in returns200OnValidRequest
(which uses signupMember() and authHeaders("kwonmo", "Test1234!")), perform an
authenticated request or token fetch using authHeaders("kwonmo", "NewPass5678!")
(or call the login/auth endpoint) and assert success (e.g., 2xx and expected
response body), and optionally try authHeaders("kwonmo", "Test1234!") and assert
it fails to further validate the change.

---

122-140: 경계값 테스트 추가 권장: 비밀번호 길이, loginId 형식

잘못된 loginId 형식 테스트는 존재하나, 비밀번호 최소/최대 길이(8자/16자) 경계값 테스트가 누락되어 있다. 경계값에서 발생하는 off-by-one 오류를 검출하기 위해 추가 테스트가 필요하다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/interfaces/api/MemberV1ApiE2ETest.java`
around lines 122 - 140, Add boundary tests in MemberV1ApiE2ETest to catch
off-by-one password length bugs: create new `@Test` methods (e.g.,
returns400OnPasswordTooShort and returns400OnPasswordTooLong) that build
MemberV1Dto.SignupRequest using ENDPOINT_SIGNUP and testRestTemplate.exchange;
for the short case submit a password of length 7 (expect HttpStatus.BAD_REQUEST)
and length 8 (expect success), and for the long case submit length 17 (expect
BAD_REQUEST) and length 16 (expect success). Reuse the same
ParameterizedTypeReference<ApiResponse<Object>> responseType and assertions
pattern from the existing returns400OnInvalidLoginId test to keep behavior
consistent.

apps/commerce-api/src/test/java/com/loopers/application/member/MemberFacadeTest.java (1)

94-108: 테스트 데이터의 비밀번호 값 혼동 가능성

인증 비밀번호(Test1234!)와 요청 본문의 currentPassword(Current1!)가 다른 값으로 설정되어 있다. 실제 운영 시나리오에서 헤더 인증 비밀번호와 변경 요청의 현재 비밀번호는 동일해야 하므로, 테스트 데이터가 실제 사용 패턴과 불일치한다.

테스트 의도가 "위임 확인"이라면 현재 구조도 가능하나, 실제 시나리오와 일치하도록 동일한 비밀번호 값을 사용하는 것이 테스트 가독성과 유지보수 측면에서 유리하다.

♻️ 수정 제안

         // when
-        memberFacade.changePassword("kwonmo", "Test1234!", "Current1!", "NewPass5678!");
+        memberFacade.changePassword("kwonmo", "Test1234!", "Test1234!", "NewPass5678!");

         // then
-        verify(memberPasswordService).changePassword(member, "Current1!", "NewPass5678!");
+        verify(memberPasswordService).changePassword(member, "Test1234!", "NewPass5678!");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/application/member/MemberFacadeTest.java`
around lines 94 - 108, The test mixes two different password values which can
confuse readers; update MemberFacadeTest so the password used in
memberAuthService.authenticate("kwonmo", ...) matches the currentPassword passed
to memberFacade.changePassword(...). Locate the authenticate stub in the test
and the memberFacade.changePassword call and use the same password string for
both the authentication step and the currentPassword argument, then keep the
verify assertion on memberPasswordService.changePassword(member,
currentPassword, "NewPass5678!") unchanged.

apps/commerce-api/src/main/java/com/loopers/infrastructure/member/MemberRepositoryImpl.java (1)

10-12: @Repository 어노테이션 사용 권장

@Component 대신 @Repository를 사용하면 Spring의 예외 변환 AOP가 적용되어 JPA 예외가 Spring의 DataAccessException으로 변환된다. 이는 데이터 접근 계층의 의도를 명확히 하고, 예외 처리의 일관성을 높인다.

♻️ 수정 제안

-import org.springframework.stereotype.Component;
+import org.springframework.stereotype.Repository;

 import java.util.Optional;

 `@RequiredArgsConstructor`
-@Component
+@Repository
 public class MemberRepositoryImpl implements MemberRepository {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/member/MemberRepositoryImpl.java`
around lines 10 - 12, Replace the generic `@Component` on the MemberRepositoryImpl
class with Spring's `@Repository` to enable exception translation for JPA
operations; specifically update the annotation on the MemberRepositoryImpl class
(remove or replace the `@Component` above public class MemberRepositoryImpl
implements MemberRepository) and add the appropriate
org.springframework.stereotype.Repository import so Spring will apply
DataAccessException translation to repository methods.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/member/MemberV1ApiSpec.java (2)

13-14: Swagger @Parameter 어노테이션 추가 권장

getMe와 changePassword 메서드의 loginId, password 파라미터에 @Parameter 어노테이션이 없어 Swagger UI에서 헤더 파라미터 설명이 표시되지 않는다. API 문서 품질 향상을 위해 추가를 고려할 수 있다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/interfaces/api/member/MemberV1ApiSpec.java`
around lines 13 - 14, Add Swagger `@Parameter` annotations for the header
parameters used by the MemberV1ApiSpec methods so the header fields show in
Swagger UI: annotate the loginId and password parameters on getMe(String
loginId, String password) and on changePassword(...) with `@Parameter`(in =
ParameterIn.HEADER, name = "loginId"/"password", description = "...", required =
true/false as appropriate) so the headers are documented; update the imports to
include io.swagger.v3.oas.annotations.Parameter and
io.swagger.v3.oas.annotations.enums.ParameterIn and ensure the method signatures
still compile.

---

16-18: ApiResponse<Object> 타입 명확화 권장

changePassword 메서드의 반환 타입이 ApiResponse<Object>로 지정되어 있다. Swagger 문서에서 응답 스키마가 불명확해지므로, 실제 반환 데이터가 없다면 ApiResponse<Void> 또는 별도 응답 DTO를 사용하는 것이 API 문서화 측면에서 유리하다.

♻️ 수정 제안

     `@Operation`(summary = "비밀번호 변경", description = "비밀번호를 변경합니다.")
-    ApiResponse<Object> changePassword(String loginId, String password,
+    ApiResponse<Void> changePassword(String loginId, String password,
                                        MemberV1Dto.ChangePasswordRequest request);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/interfaces/api/member/MemberV1ApiSpec.java`
around lines 16 - 18, The method changePassword currently returns a generic
ApiResponse<Object> which makes the Swagger response schema ambiguous; update
the method signature in MemberV1ApiSpec by replacing ApiResponse<Object> with a
more specific response type (preferably ApiResponse<Void> if there is no
response body, or a dedicated DTO if you intend to return data), e.g., change
the return type for changePassword(String loginId, String password,
MemberV1Dto.ChangePasswordRequest request) to ApiResponse<Void> and adjust any
related API docs/tests to match.

apps/commerce-api/src/main/java/com/loopers/domain/member/Password.java (1)

25-36: 비밀번호 복잡도 검증 추가 권장

현재 검증은 길이(8-16자)와 허용 문자만 확인하므로, "aaaaaaaa"처럼 영문자만으로 이루어진 약한 비밀번호도 허용된다. 보안 강화를 위해 대문자, 소문자, 숫자, 특수문자 중 최소 3가지 이상 조합을 요구하도록 검증 로직을 추가하고, 약한 비밀번호를 거부하는 테스트 케이스를 포함하도록 한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/commerce-api/src/main/java/com/loopers/domain/member/Password.java`
around lines 25 - 36, The Password constructor currently only checks null/blank,
length, and ALLOWED_PATTERN; add a complexity check in Password(String value)
that verifies the value contains at least three of the four character classes
(uppercase, lowercase, digit, special) and throw new
CoreException(ErrorType.INVALID_PASSWORD) if the requirement is not met;
implement the check using simple boolean predicates (e.g., containsUpper,
containsLower, containsDigit, containsSpecial) based on the existing
ALLOWED_PATTERN or Character methods and count the true predicates, and
update/add unit tests to assert that weak passwords like "aaaaaaaa" or
"AAAA1111" are rejected while valid complex passwords pass.

apps/commerce-api/src/main/java/com/loopers/domain/member/MemberModel.java (1)

46-48: 도메인 엔티티가 Spring Security 타입에 직접 의존한다.

이 의존성 때문에 encoder 구현을 바꾸는 작업이 도메인 엔티티 API 변경으로 번지고, 순수 도메인 테스트도 프레임워크 mock에 묶인다. 비밀번호 비교는 서비스나 도메인 포트로 옮기고, 엔티티는 해시 보관과 상태 변경만 담당하도록 분리하는 편이 유지보수와 장애 범위 관리에 유리하다. 추가로 같은 패턴이 domain 패키지 전체에 퍼져 있는지도 확인하고, 엔티티 테스트는 Spring 없이 수행하며 encoder 연동은 서비스 테스트에서 검증해야 한다.

As per coding guidelines, **/domain/**/*.java: 도메인 규칙과 인프라 관심사가 섞이면 분리하도록 제안한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/commerce-api/src/main/java/com/loopers/domain/member/MemberModel.java`
around lines 46 - 48, MemberModel currently depends on Spring Security
PasswordEncoder via the matchesPassword method; remove this direct framework
dependency by deleting matchesPassword from MemberModel and instead expose the
stored hash (e.g., getPassword or getPasswordHash) and a state-changing method
for setting/changing the hashed password (e.g., setPasswordHash or
changePasswordHash) so the entity only stores and updates hashes. Move the
responsibility for raw-password verification into the application/service layer
or a domain port (e.g., MemberService or a PasswordVerifier port) where
PasswordEncoder can be injected and used (call encoder.matches(rawPassword,
member.getPasswordHash())). Also update tests: keep pure domain/entity tests
framework-free and add service-level tests that verify encoder integration; scan
other classes in the domain package for similar PasswordEncoder usages and
refactor them the same way.